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ABSTRACT 


The National Aeronautics and Space Administration Dryden Flight Research Center (Edwards, 
California) is conducting ongoing flight research using adaptive controller algorithms. A highly modified 
McDonnell-Douglas NF-15B airplane called the F-15 Intelligent Flight Control System (IFCS) is used to 
test and develop these algorithms. Modifications to this airplane include adding canards and changing the 
flight control systems to interface a single-string research controller processor for neural network 
algorithms. Research goals include demonstration of revolutionary control approaches that can efficiently 
optimize aircraft performance in both normal and failure conditions and advancement of neural-network- 
based flight control technology for new aerospace system designs. 

This report presents an overview of the processes utilized to develop adaptive controller algorithms 
during a flight-test program, including a description of initial adaptive controller concepts and a 
discussion of modeling formulation and performance testing. Design finalization led to integration with 
the system interfaces, verification of the software, validation of the hardware to the requirements, design 
of failure detection, development of safety limiters to minimize the effect of erroneous neural network 
commands, and creation of flight test control room displays to maximize human situational awareness; 
these are also discussed. 
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AIU 
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API 
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betad 
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CAT 

cc 

CIU 

DAG 

DFRC 

DLL 

DR 

FC 

FCC 
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Gen2_p_ad 

Gen2_q_ad 

Gen2_r_ad 

G 


aileron 

angle of attack, deg 
normal acceleration, g 
aircraft stability derivatives 
avionics interface unit 
analog multiplexer 
application program interface 
Airborne Research Test System 
angle of sideslip, deg 
aircraft control derivatives 
basis function 
canard 

neural network input categoiy 

Choose-a-Test 

central computer 

cockpit interface unit 

Dial-a-Gain 

Dryden Flight Research Center 
design limit load 
discrepancy report 
flight computer 
flight control computer 
acceleration of gravity 
Generation 2 roll adaptive command 
Generation 2 pitch adaptive command 
Generation 2 yaw adaptive command 
adaptation gain 



HWCI 

hardware configuration item 

iadadag 

ada source of Dial-a-Gain 

iadapal 

ada source of Pick-a-Limit 

IADS 

Interactive Analysis and Display System 

IFCS 

Intelligent Flight Control System 

I/O 

input/output 

kron 

nested Kronecker product 

K d 

derivative gain 

Ki 

integral gains 

Kp 

proportional gain 

K z 

learning gains 

K z . 

H 

learning gains integral 

L 

error-modification term 

MCC 

Mission Control Center 

MPD 

multi-purpose display 

MPDP 

multi-purpose display processor 

MUX 

multiplex 

NASA 

National Aeronautics and Space Administration 

NN 

neural network 

NVRAM 

non-volatile random access memory 

Ny 

y-axis normal load factor 

N z 

z-axis normal load factor 

OFP 

operational flight program 

P 

roll rate, deg/s 

pbodyd 

roll rate body axis, deg/s 

phi 

roll angle 

phid 

roll angle, deg 

p-i-d 

proportional-integral-derivative 

PAL 

Pick-a-Limit 

PC 

personal computer 

PID 

parameter identification 

PLA 

power level angle 

PTC 

portable test computer 

PVI 

pilot-vehicle interface 

q 

pitch rate, deg/s 

qbodyd 

pitch rate body axis, deg/s 

r 

yaw rate, deg/s 

rbodyd 

yaw rate body axis, deg/s 

rud 

rudder 

stab 

stabilator 

SES 

simulation electric stick 

SW 

software 

thetad 

pitch angle, deg 

U ad 

augmentation command 

U dd 

error compensation commands 

U 

surface positions 

u c 

surface deflections commands 

V&V 

verification and validation 


2 



w 

neural network weights 

w 

neural network weight derivative 

W T 

neural network weight transpose 

X 

aircraft state 

X 

aircraft state derivative 

x e 

aircraft state error 

x e 

aircraft state derivative command 

x ref 

angular body axis rate 

x re f 

angular body axis acceleration 

Z 

neural network learning signal 


INTRODUCTION 


There is interest in investigating possible future technologies by performing flight-test research using 
neural network (NN) adaptive controllers. The use of NN and similar adaptive technologies in the design 
of highly fault- and damage-tolerant flight control systems shows promise toward increasing the 
survivability of future aircraft by maintaining the integrity of the flying qualities of the aircraft as much as 
possible in the presence of certain failures. Addressing this challenge, the National Aeronautics and Space 
Administration Dryden Flight Research Center (DFRC) at Edwards Air Force Base (AFB) (Edwards, 
California) formed the F-15 Intelligent Flight Control System (IFCS) program, which uses a highly 
modified McDonnell-Douglas NF-15B test airplane (tail number 837) to conduct research. The F-15 
IFCS airplane, shown in fig. 1, incorporates a quadraplex all-digital flight control system that interfaces 
with the NN processor; the addition of canards; and thrust-vectoring nozzles. 
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Extensively modified F-15 airframe 


Quadraplex digital flight control system 
No mechanical or analog backup 
Research control law processor 
(enhanced mode) 


Thrust vectoring nozzles 


Airborne Research Test System computer for added 
computational capability (neural network algorithm) 


Figure 1. The F-15 Intelligent Flight Control System airplane, tail number 837. 


3 



Early in the F-15 IFCS program, a design decision was made to interface the NN controller in a single 
processor with the existing flight control computers (FCCs). This single-string approach rendered the 
software and hardware less complicated, but added risk due to lack of redundancy. This report presents 
the processes used to develop adaptive controller algorithms throughout the progression of a flight-test 
program. Many challenges existed toward making this research cost-effective, timely, efficient, and, most 
importantly, safe; an overview of the tasks related to these challenges is presented. Some of the 
approaches discussed herein may be applied to future flight-test activities. 

SIMULINK® ALGORITHMS 


The NN adaptive flight control system architecture, shown in figure 2, is based on the augmented 
model inversion controller developed by Calise, Lee, and Sharma (ref. 1), and Rysdyk and Calise (ref. 2). 
An explicit model-following scheme is used to achieve the desired handling qualities. This direct adaptive 
approach integrates feedback linearization theory with on-line learning sigma-pi NNs. These networks 
generate command augmentation signals to compensate for errors in the model inversion. A Lyapunov 
stability proof guarantees boundedness of the tracking error and network weights. 


x ref 



Figure 2. The neural adaptive flight control system architecture. 

The pilot generates flight commands through longitudinal and lateral stick deflections and use of the 
rudder pedals. The flight commands are then filtered through reference models that produce angular body 
axis rate ( x re j ) and angular body axis acceleration ( x re j ) signals with the desired frequency and 

damping characteristics (ref. 3). Dynamic inversion is then used to compute the necessary surface 
deflections commands ( u c ) to achieve the desired accelerations. If the dynamic inversion and aircraft 
dynamics behaved together as a perfect integrator, then the response of the aircraft would match the 
reference models. Since errors are introduced by inaccuracies in the inversion, however, proportional- 
integral-derivative (p-i-d) controllers are necessary to generate error compensation commands ( U ^ ), as 
shown in equation (1) below, 


Udd = Ki\ 


x e + K p x e + KrfX e 


( 1 ) 


where x e is the state error, K p is the proportional gain, and K c j is the derivative gain. 
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The NNs work in conjunction with the p-i-d controllers by recognizing error patterns and learning 
how to compensate for them through the generation of augmentation commands ( U ac i ). The selected NN 
inputs consist of sensor feedback (for A- matrix failures), control commands 
(for 5-matrix failures), and bias terms (for out-of-trim conditions). These inputs are normally separated 
into different neural network input categories ( C ), which are then combined together to form a basis 
function ( B a ) using nested Kronecker products, as shown in equation (2) below. 

B a = kron ( kron ( C\, C ’2 ) , C 3 ) . . . (2) 

This basis function can then be used to update the neural network weights ( W ) with an adaptation 
law, as shown in equation (3) below, and to compute the augmentation command ( U ac ] ), as shown in 
equation (4) below. 


W =-G(ZB a + L\Z\W) 

( 3 ) 

Uad = W T B„ 

( 4 ) 


The adaptation gain (G) specifies how fast the weights will adapt. The error-modification term (L ) 
helps to contain the growth of the weights. The neural network learning signal ( Z ) is computed as a 
function of error, as shown in equation (5) below, with learning gains ( K z ) that are conditionally based 

upon the dynamic inversion p-i-d controller gains. In equation (5), the subscripts p and d refer to 
proportional and derivative, respectively. 

Z = K z . J x e + K Z p x e + x e ( 5 ) 

The role of dynamic inversion is provided by a pseudo-inverting Versatile Control Augmentation 
System (VC AS), developed by the Boeing Phantom Works at Saint Louis, Missouri (The Boeing 
Company, Chicago, Illinois). The objectives of this improved adaptive controller algorithm, Generation 
2a, called Gen 2a, will now be discussed. 

Generation 2a Enhancements 

The performance objectives of the F-15 NN adaptive flight control tests include restoring 
model-following tracking performance, reducing cross-coupling effects, and reducing initial transients 
caused by failure insertion. For piloted aircraft applications, the NNs must adapt quickly enough to assist 
pilots in controlling a damaged aircraft, yet avoid learning transients that could interfere with the pilot’s 
ability to control the aircraft during adaptation. The Gen 2a enhancements improved the performance of 
the adaptive system (ref. 4). The design team processed equations (1) through (5) into MATLAB® and 
Simulink® (both registered trademarks of The MathWorks, Inc., Natick, Massachusetts) block diagrams. 
Figure 3 shows the top level of the flight control system with NNs that were processed by Simulink R 
AutoCode into the C computer language. 

From figure 3, the block diagram is broken down into a smaller Simulink® AutoCode subsystem 
shown in figure 4. At this time the Simulink® AutoCode is generated which is used in the six-degrees-of- 
freedom simulation and eventually in the aircraft FCC in the form of an operational flight program (OFP). 
The OFP is the final step after many tests have been performed in the six-degrees-of-freedom simulation, 
including pilot-in-the-loop testing. 
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Figure 3. The top level of the flight control system with neural networks. 
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Figure 4. The Simulink® AutoCode block diagram. 


AIRBORNE RESEARCH TEST SYSTEM SOFTWARE DEVELOPMENT 


The airborne research test system (ARTS) is a flight-ruggedized processor system dedicated to the 
execution of flight research software, in this case NN adaptive control. The ARTS was developed by the 
West Virginia Fligh Technology Consortium (WVHTC) Foundation (Fairmont, West Virginia) in support 
of the IFCS. The architecture is a system of three single-board computers with a variety of input/output 
(I/O) options to support a large set of potential research initiatives. Each computer is a 400 Mhz PowerPC 
with 256 MB of RAM. Two of the computers are dedicated to the execution of research, and one 
computer handles the system interfaces. Inter-board communication is performed using the VME 
backplane. All single-board computers run the VxWorks" (Wind River Systems, Inc., Alameda, 
California) real-time operating system. 
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The baseline ARTS software load has no pre-knowledge of the research algorithms that it will be 
executing. An executive framework is in place to handle the communication with the aircraft data buses, 
and an application program interface (API) mechanism allows research experiments to register their 
existence and communicate, via the I/O computer, with the aircraft flight controls. This architecture keeps 
the ARTS generic while providing an interface to the aircraft for the research experiments. 

Research flown on the ARTS to date has been developed using the MathWorks Simulink software 
development environment. The process of integrating the Simulink® model into the ARTS involves 
Simulink 1 * AutoCoding the model to the C computer language and later importing to a PowerPC. The 
Simulink” model conversion process is shown in figure 5. A wrapper of C-language hand code is then 
written around the I/O of the model to receive and forward the aircraft state data to the Simulink® 
AutoCoded model as well as to transmit command augmentations from the model back to the aircraft 
flight controls. This transfer of information is achieved using the APIs provided by the flight executive. 
Additionally, APIs are provided to record any required state data of the model to non-volatile random 
access memory (NVRAM) solid-state disk drives within the ARTS. These disk drives may be retrieved 
post-flight for additional analysis. 
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Figure 5. The Simulink" model conversion process. 

Validating proper integration of the Simulink" model is a three-phase process. The developer of the 
model provides a check-case with a set of inputs and a set of expected outputs. That check-case is first 
executed within the native Simulink” environment to validate that it matches on the machine that will 
perform the Simulink" AutoCoding. The Simulink” model is then Simulink” AutoCoded to the C 
language. The C code and the check-case are then executed again on a host processor (typically a UNIX 
derivative) to validate that the check-case still matches. The check-case validation architecture is shown 
in figure 6. Once confidence in the C code is established, the code is compiled for VxWorks” and 
integrated with the ARTS APIs. The check-case is then executed using a hardware-in-the-loop simulation 
(HILS). This HILS is executed on a PC with 1553 I/O capabilities that simulate the 1553 buses on the 
aircraft. The results of the check-case are compared against the original for an acceptable tolerance. The 
check-case will never match exactly due to the fact that 64-bit floating point signals are scaled to 1 6 bits 
for insertion on the 1553 bus. 
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Figure 6. The check-case validation architecture. 
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AIRBORNE RESEARCH TEST SYSTEM DESIGN 


The ARTS architecture showing its interface with the F-15 IFCS is shown in figure 7. The ARTS is a 
remote terminal (RT) to the FCC and the central computer (CC). It is a bus controller to the 
instrumentation systems and also features an analog multiplexer (AMUX) card to interface with analog 
signals. The NN experiment options are controlled by the pilot using the existing multi-purpose display 
(MPD) panel in the cockpit. This display panel allows a pilot-vehicle interface (PVI) with the ARTS. The 
NN algorithm engagement options, along with variable gain sets for each function, can be controlled by 
the pilot. The gain sets are used to alter the states within the model and provide a means to configure the 
software without a necessitating a recompile. 
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Figure 7. The F-15 Intelligent Flight Control System architecture. 


Pilot-Vehicle Interface 

Three functions are used to select the experiment configuration and options: Pick-a-Limit (PAL); 
Dial-a-Gain (DAG); and Choose-a-Test (CAT). An image of the MPD showing these options is presented 
in figure 8. 

The PAL is used to define the flight limits. There are two possible flight envelope ranges, depending 
on the PAL number selected, as shown in table 1 . If any of the parameters shown in table 1 are outside of 
the flight envelope range, the system will downmode to the conventional flight control laws. A unique 
downmode flag is set on the 1553 bus and monitored in the mission control center (MCC). 
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Figure 8. The multi-purpose display Intelligent Flight Control System functions. 


Table 1. Pick-a-Limit flight envelope limits. 


Parameter 

Envelope #1 (PAL 0-7) 

Envelope #2 (PAL 8-15) 

Lower limit 

Upper limit 

Lower limit 

Upper limit 

Angle of attack 

-4.0 deg 

12.0 deg 

-4.0 deg 

12.0 deg 

Sideslip angle 

-5 deg 

5 deg 

-5 deg 

5 deg 

Pitch angle 

-180 deg 

180 deg 

-180 deg 

180 deg 

Bank angle 

-90 deg 

90 deg 

-180 deg 

1 80 deg 

Pitch rate 

-45 deg/sec 

45 deg/sec 

-60 deg/sec 

60 deg/sec 

Roll rate 

-75 deg/sec 

75 deg/sec 

-300 deg/sec 

300 deg/sec 

Y aw rate 

-15 deg/sec 

15 deg/sec 

-60 deg/sec 

60 deg/sec 

Normal acceleration [1] 

-1 g 

2-1 g 

-2.0 g 

5.0 g 

Lateral acceleration 

-0.5 g 

0.5 g 

-1.0 g 

1.0 g 

Mach number 

0.55 

0.95 

0.55 

0.95 

Qbar 

253 psf 

733 or 550 psf 2 

253 psf 

733 or 550 psf 2 

Altitude 

15,000 ft 

35,000 ft 

15,000 ft 

35,000 ft 

Pitch stick 

-3.1 in 

5.46 in 

-3.1 in 

5.46 in 

Roll stick 

-4.0 in 

4.0 in 

-4.0 in 

4.0 in 

Yaw pedal 

-3.25 in 

3.25 in 

-3.25 in 

3.25 in 

Throttle (PLA) 

16.5 deg 

130 deg 

16.5 deg 

130 deg 

Discrete switches 




PAL 15 only 

Flap up mode 

1 U 


1 U 

2 DM 

Landing gear up 

2 DM 


2 DM 

0 LGD 

Throttle switch up 

2 DM 


2 DM 

2 DM 

Spin mode 

0NS 


0NS 

0NS 

Weight on wheels 

0 NGC 


0 NGC 

1 GC 


Legend for discrete switches: DM = doesn’t matter; GC = ground contact; LGD = landing gear down; 
NGC = no ground contact; NS = no spin; U = up. 
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For every PAL selected there is a DAG option which can be engaged to either create a particular type 
of failure in the FCC (a stabilator lock or a canard gain multiplier) or a surface excitation signal for 
parameter identification (PID) testing. There are eight DAG sets, one of which is shown in table 2. In this 
example, various stabilator lock values or canard multiplier failures may be set by the FCC. An excitation 
signal may also be activated after a failure is set, or the excitation signal can be commanded 
independently. 


Table 2. Dial-a-Gain options. 


PAL 

DAG 

Flying 

qualities 

Failure 

Excitation 

Qbar limit 


20 

Baseline 

None 

None 

733 psf 


21 

Baseline 

4 deg left stabilator lock 

None 

550 psf 


22 

Baseline 

2 deg left stabilator lock 

None 

733 psf 


23 

Baseline 

0 deg left stabilator lock 

None 

733 psf 


24 

Baseline 

-2 deg left stabilator lock 

None 

733 psf 


25 

Baseline 

-4 deg left stabilator lock 

None 

550 psf 


26 

Baseline 

-0.5 canard failure multiplier 

None 

550 psf 

1 or 8 

27 

Baseline 

-0.2 canard failure multiplier 

None 

733 psf 

28 

Baseline 

0 canard failure multiplier 

None 

733 psf 


29 

Baseline 

0.1 canard failure multiplier 

None 

733 psf 


30 

Baseline 

0.2 canard failure multiplier 

None 

733 psf 


31 

Baseline 

0.4 canard failure multiplier 

None 

733 psf 


32 

Baseline 

0.6 canard failure multiplier 

None 

733 psf 


33 

Baseline 

0.8 canard failure multiplier 

None 

733 psf 


34 

Baseline 

None 

None 

733 psf 


35 

Baseline 

None 

None 

733 psf 


The CAT page is used to engage a particular NN for flight-testing, as shown in table 3. There were 
three NNs available in the ARTS OFP with possible beta sources as an input to the NN. The option to 
select multiple beta sources was added to the NN gain set files because of the uncertainty of the quality of 
the beta signal. This design allowed for particular configuration changes to be made without having to 
create and compile a new OFP. These configuration files, called CONFIG files, included unique options 
within the NN for each CAT. 
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Table 3. Choose-a-Test options. 


CAT# 

Neural network type 

Beta source 

40 

None 


41 

NN 1 sigma Pi baseline 

N/A 

42 

NN 1 sigma Pi option 1 

N/A 

43 

NN 1 sigma Pi option 2 

N/A 

44 

NN 1 sigma Pi option 3 

N/A 

45 

NN 1 sigma Pi option 4 

N/A 

46 

NN2 scalar baseline 

Nose boom beta 

47 

NN2 scalar option 1 

Filtered nose boom beta 

48 

NN2 scalar option 2 

CC beta 

49 

NN2 scalar option 3 

Estimated beta 

50 

NN3 scalar baseline 

Nose boom beta 

51 

NN3 scalar option 1 

Filtered nose boom beta 

52 

NN3 scalar option 2 

CC beta 

53 

NN3 scalar option 3 

Estimated beta 

54 

None 


55 

None 



Configuration Files 

The CONFIG files for the NNs included options to modify various parameters such as gains, limits, 
deadzones for each feedback signal, upper and lower weight limits, surface limits, and flags. A software 
tool was developed to ftp the existing configuration files from the ARTS OFP, replace the files that had 
been modified, recompute the checksums, and create a new zipped TAR file for import to the ARTS OFP. 

Non-volatile Random Access Memory 

The ARTS OFP provided for a set of NN signals to be written to NVRAM within the processor. Each 
time the NN was engaged, a predefined data set began writing to the NVRAM and continued until the NN 
was disengaged. The data file was retrieved from the ARTS after the flight using a portable test computer 
(PTC) that interfaced with the ARTS using an Ethernet connection. 

Log Files 

In addition to the NVRAM files the ARTS wrote log files, which provided status information such as 
modes transitions, errors, and file opening or closing status. The log file was retrieved after each flight 
and was particularly useful for troubleshooting. An excerpt from a log file is shown immediately below. 
The log file segment shown has flagged transition events within the ARTS of an NN engagement 
(CAT 51). 
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01:29:14, 321483, Severity: SUCCESS, Task:exec, Procedure:state_change.c, Detciils:Exec 
transitioned from the DISENGAGED to the ENGAGED state because FC requested Engagement 

01:29:52, 323816, Severity INFORMATIONAL, Task:exec, Procedure:process_cats.c, 

Details: CAT value of 51 coupled 

01:29:58, 324169, Severity INFORMATIONAL, Task:exec, Procedure.mode.c, Details:CAT 
mode changed from NOT COUPLED to COUPLED 

01:30:09, 324802, Severity INFORMATIONAL, Task: exec, Procedure.mode.c, Details: CAT 
mode changed from COUPLED to CL_NN 

FORMAL VERIFICATION AND VALIDATION TESTING 


The verification and validation (V&V) of the new NN software release was performed in-house by 
NASA DFRC IFCS project personnel. An overview of the DFRC simulation architecture is shown in 
figure 9. The simulation featured a cockpit for piloted simulations with a projection screen for situational 
awareness, a full six degrees of freedom, hardware interfaces for the ARTS and the CC, and a functional 
MPD in the cockpit. A PTC was used to load and retrieve files in the ARTS. A PASS 3200 1553 bus 
analyzer was part of the PTC and was used for bus testing. All of the NN OFP V&V was performed with 
this system. 
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Figure 9. The F-15 Intelligent Flight Control System NASA Dryden simulation architecture. 

The software V&V process is shown in figure 10. A formal V&V test plan was written, which 
included absolute requirements that are referred to as “shall statements.” Test procedures that contained 
simulation scripts for the test inputs and recorded output files were written for each requirement. This 
method produced more repeatability in the results and a faster, more automated execution of the 
procedures. All results referenced the test requirement “shall statement number.” A PASS or FAIL 
criteria was applied to the test results by both the test conductor and a witness. A test results document 
containing subsets of the recorded testing data was written. All failed tests were documented in 
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discrepancy reports (DRs). The DRs were categorized as a required fix, a minor limitation, or a procedure 
work-around. When a failed test was encountered, the tests continued to completion. The only exception 
was if the failed test was unacceptable and required a new OFP; for these tests there were no DRs in this 
category, however, there were DRs that were corrected at the conclusion of the V&V by using a new 
configuration file that did not require a new OFP. A selected subset of retests were performed for 
regression testing to complete the final V&V. Other discrepancies were found that would have required a 
new OFP, but these were considered minor, were consequently carried as DRs against the system, and 
were not fixed. 



Figure 10. The software verification and validation process. 

Verification and Validation Testers 

Verification and validation tests were divided among the IFCS team according to the team members’ 
area of expertise. The testing included: corrected DRs; new system requirements; comparisons of 
software versus hardware for no NN; NN(123) without failures; NN(123) with failures; 1553 bus testing; 
NVRAM; configuration files; piloted evaluations of the NN performanace and NN disengagement 
transients; simulated structural loads; OFP path coverage; and failure modes and effects testing (FMET). 

Sample Verification and Validation Test Results 

Four sets of sample sample test verification test results are shown in figures 11(a) through 11(d). 
Attitudes, rates, and accelerations are shown in figures 1 1(a) and 1 1(b); surface positions comparisons are 
shown in figure 11(c); and NN commands are shown in figure 11(d). These time histories show the 
comparisons of the all-software version of the NN versus the NN interfaced with the simulation from the 
ARTS hardware. A simulation script was used to generate pitch, roll, and yaw stick and rudder pedal 
doublets. 
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IFCS F-15: Longitudinal 
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(a). Simulation comparisons of software versus hardware, Airborne Research Test System, set 1. 

Figure 11. Simulation comparisons of software versus hardware, Airborne Research Test System, sets 1 
through 4. 
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IFCS F-15: Lateral-directional 
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(b). Simulation comparisons of software versus hardware, Airborne Research Test System, set 2. 

Figure 11. Continued. 


15 


Rud Stab Can 


IFCS F-15: Surfaces 






sw_arts_w_cockpit_p8_d25_c51_sw-hw73.cmp4 
hw arts p8 d25 c51 sw-hw73.cmp4 

090101 


(c). Simulation comparisons of software versus hardware, Airborne Research Test System, set 3. 

Figure 11. Continued. 
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IFCS F-15: Neural network adaptive signals 
PAL 8, DAG 25, CAT 51 , Ver 4.2 
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(d). Simulation comparisons of software versus hardware, Airborne Research Test System, set 4. 

Figure 11. Concluded. 

A sample of a piloted validation evaluation test card is shown in figure 12. This test was a handling 
qualities evaluation using one of the NN designs; the NN performed as expected. There were numerous 
test cards flown to evaluate each NN for nominal, with induced DAG-type failures, various piloted 
maneuvers and flight conditions, disengage transients, and system-type fault insertions. All of the results 
of these tests were determined to be acceptable. 
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CARD: HQ-02 


TEST: ENVELOPE TOLERANCE TEST WITH GEN-2A ENGAGED 
AND NO FAILURE 

TEST PURPOSE: VERIFY THAT THE GEN-2A ADAPTIVE SYSTEM EXHIBITS ACCEPTABLE HANDLING QUALITIES FOR 
THE OFF-NOMINAL FLIGHT CONDITION, NO FAILURES 
TEST NOTES: THIS TEST WAS PERFORMED BY AN ENGINEERING PILOT. 

REQUIREMENTS: 6.7.I-1. 

TEST RESULTS: ALL PAL, DAG AND CAT SELECTIONS WORKED AS EXPECTED, AND THE AIRPLANE ENGAGED AND 

DISENGAGED PROPERLY. AT THE BOTH THE HIGH-QBAR AND LOW-QBAR TEST CONDITIONS, THE 
AIRCRAFT EXHIBITED GOOD FLYING CHARACTERISTICS FOR THETA CAPTURES, BANK-TO-BANK 
TURNS AND 3-G WINDUP TURNS. 

ENGAGE TRANSIENTS LEVELS: NONE 


DISENGAGE TRANSIENTS LEVELS: (NZ AND NY IN G’S, R IN DEG/SEC) 


Manuever 

nz 

High Qbar 

ny 

r 

nz 

Low Qbar 

ny 

r 

theta captures 

0.0 

0.08 

0.7 

0.0 

0.03 

0.25 

bank-to-bank turns 

0.0 

0.06 

0.3 

0.0 

0.03 

0.25 

3-g wind-up turns 

0.0 

0.07 

0.35 

0.0 

0.03 

0.35 


During the high- and low-qbar tests, yaw-axis weights #1, 3, 4 and 6 continued to grow throughout each test, producing a growing 
gen2_r_ad command. However, their values remained small (much less than one) and resulted in minor yaw rate disengage transients. 
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Figure 12. A sample piloted evaluation flight card. 


SAFETY MONITORS 


The NN controller is a single-string interface to the FCC, therefore, the primary concern was that the 
worst-case failure would likely be an erroneous NN command hardover (rapid and sustained displacement 
of an aircraft aerodynamic control surface) to the FCC control laws. This type of command could result in 
excessive structural loads and g acceleration excursions to the aircraft. The pilot also imposed an 
additional requirement of no more than +0.5 g lateral and +2 g normal accelerations from trimmed flight 
for any disengagement transient. Safety monitors, which would disengage the NN and revert to the 
conventional control laws for most failures, were added in the FCC processors. These safety monitors will 
now be described. 


Pick-a-Limit Monitor 

The PAL monitor generates a downmode from the NN when any limit is exceeded, as was briefly 
described in the “Pilot-Vehicle Interface” section above. If any limit was exceeded, the IFCS would revert 
to the conventional control system. This monitor, however, did not prevent the g limits from being 
exceeded for a NN hardover. A graphical representation of this problem is shown in figure 13. An NN 
hardover was inserted in the pitch-up direction, causing the PAL limiter to trigger a disengagement at 6 g, 
but due to the momentum of the aircraft, the response peaked at approximately 10.5 g. A similar result for 
the roll axis is shown in figure 14. In this case, the PAL safety monitor was never set because the lateral 
acceleration never reached the limit. These responses are both unacceptable, thus, a new monitor, called a 
floating limiter, was developed and added to the FCC software. The floating limiter proved to be a much 
better concept for controlling both the structural loads and g excursions. As shown in figures 13 and 14, 
this new monitor limited the g excursion to approximately 2.3 g, which was far more effective in 
producing the desired results. 
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Lateral acceleration, g Normal acceleration, 
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Sigma pi pitch command hardover from trimmed flight, 
Mach 0.9 and an altitude of 25,000 ft. 



N z limiter 

N z no limiter 

File = cdcl.dat: Signal Suffix = .sm: Date = (none) 
File = cdc2.dat: Signal Suffix = .nosm: Date = (none) 


090104 


Figure 13. Normal acceleration response due to an Airborne Research Test System pitch hardover. 


Sigma pi roll command hardover from trimmed flight, 
Mach 0.9 and an altitude of 25,000 ft. 


Floating 
limiter drift 
boundary hit 

^Enhanced 
/ disengagement 

— 

/ No enhanced 


' / disengagement 


, (entire run) 

, 

V 1 1 1 


Ny limiter 

Ny no limiter 

File = cdc3.dat: Signal Suffix = .sm: Date = (none) 
File = cdc4.dat: Signal Suffix = .nosm: Date = (none) 


0 2 4 6 8 10 12 


Time, s 
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Figure 14. Lateral acceleration response due to an Airborne Research Test System roll hardover. 


Floating Limiter 

The floating limiter safety monitor (ref. 5) was required to allow full surface authority at the 
maximum actuator rates if required by the NN control laws while still protecting the pilot and aircraft 
from excessive forces in the case of a commanded hardover. 
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The floating limiter monitor automatically engages when the NN is activated, and works by 
computing the rate of change for each NN command and applying a moving upper and lower boundary 
limits window. The floating limiter structure is shown in figure 1 5 . Full surface authority at the maximum 
actuator rates (within the moving window) is achieved, but with the limitation that the stick must be 
pulled back no faster than the drift rate of the floating limiter. This limiter and procedure still allow for 
normal piloted maneuvers such as wind-up turns, which is a reasonable compromise. The window 
constantly tries to center about the NN command rate, but is programmed to move at a much slower drift 
than is possible from NN command rates. This algorithm provides the desired protection from a 
commanded hardover. The NN command rates within the window boundaries are allowed to change at 
maximum rates since the commands are not in any one direction long enough to cause problems. If the 
NN command does persist in one direction, however, it will “catch up” with the floating limiter boundary 
and will be temporarily rate-limited to that value. When rate-limiting occurs, a persistence counter starts 
and a signal is sent to the NN control laws to stop learning. When the limit is reached for the persistence 
counter, a downmode command is generated. A maximum and minimum range limiter that would cause a 
disengage was also included. 


Upper range limit 


Maximum drift rate 


Neural network command 


Floating limiter boundary 



Lower range limit 
Time ► 
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Figure 15. The floating limiter structure. 

One of the problems in implementing the floating limiter was the desire to make the monitor very 
tight when the NN is initially engaged but no failures have been induced (a very small NN command), 
then open the limits after the failure is in a transition phase, and finally change the limits again after the 
failure has stabilized so the NN is allowed to generate the necessary commands to compensate for the 
failure without causing a downmode. This was solved by developing three floating limiter regions, as 
shown in figure 16. The set of constants used for the floating limiter is shown in table 4. These parameters 
were tuned using the DFRC simulator to meet the +0.5 g lateral, +2 g normal accelerations, < 80% design 
limit load (DLL) requirements. Drift rates are independently set according to the axis, failure type, and 
magnitude. The drift, persistence, downmode, and range flags were added to a 1553 message from the 
FCC to the ARTS; these signals were also available on the instrumentation system for monitoring in the 
MCC. 


20 


Table 4. Floating limiter constants metrics. 


Right stabilator failure from trim 
fldrifttableconffile [] [] [] 

P axis 

Q axis 

R axis 

0 deg and no fail, dps 3 
transition 

150 

50 

0.03 

final 

500 

90 

0.01 

+2 deg, dps ’ 
transition 

230 

60 

0.03 

final 

700 

60 

0.02 

+ 4 deg, dps 3 
transition 

430 

60 

0.03 

final 

850 

60 

0.09 

-2 deg, dps J 
transition 

230 

60 

0.03 

final 

525 

60 

0.02 

-4 deg, dps 3 
transition 

430 

60 

0.03 

final 

550 

60 

0.09 

Canard angle of attack fails 

Set 1, dps 3 
transition 

100 

1 

0.03 

final 

100 

1 

0.03 

Set 2, dps 3 
transition 

100 

20 

0.03 

final 

100 

20 

0.03 

Metrics 

Initial drift, dps 3 
fl init drift conf file[] 

1.0 

1.0 

0.01 

Delta, dps 2 
fl delta conf file[] 

200 

52 

0.10 

Range limit, dps 2 
fl hard range conf file[] 

775 

300 

0.2 

Persistence time, s 
fljpersistence time conf file[] 

0.25 

0.10 

0.25 

Transition time, s 

1 . 



fl transition time conf file 

D 
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Figure 16. The floating limiter regions. 

LOADS MODEL 


The adaptive control algorithms were tested against the allowable load envelope of the IFCS airplane 
by running batch simulations of the loads clearance maneuvers with the analytical loads model in the loop 
(1 g half-stick 360° rolls, 4 g wind-up turns, and 3 g loaded roll reversals). These tests caused the floating 
limiter to detect an excessive rate of change in the NN commands, which resulted in a disengagement and 
return to the baseline conventional control laws, in each case hopefully before the loads exceeded 80% 
design limit load (DLL). Each batch simulation run consisted of selecting a loads clearance maneuver and 
inserting the hardover command at one time frame in the simulation; this was repeated at successive 0.5-s 
intervals for the duration of the maneuver. Thus, a 20-s maneuver generated 40 ARTS hardover runs. Any 
test conditions that showed a simulated ARTS failure to generate over 80% DLL on any of the load 
stations were not flown unless further analysis indicated that the pre-programmed stick inputs were 
partially responsible for high accelerations or surface positions. In these cases, additional runs were 
conducted using recorded pilot inputs to drive the batch simulation. If these runs showed less than or 
equal to 80% DLL, the suspect test conditions were flown. It should also be noted that in a few cases the 
floating limiter was too efficient, and would downmode within a few time frames of engagement or 
during the maneuver. This was typically due to exceeding the pitch rate floating limiter, and occurred on 
the largest stabilator-lock and canard multiplier cases. These difficulties were overcome by using pre- 
recorded pilot input files to drive the batch simulation; the human pilot was able to compensate for the 
reduced stability at the higher canard multipliers and the pilot-induced oscillation (PIO) tendency with the 
largest stabilator-lock. The 80% DLL cutoff was selected to give the airframe extra margin to compensate 
for uncertainty in the loads model and the adaptive controller algorithm. 

The floating limiter algorithm prevents ARTS hardover commands from propagating to the FCC, thus 
preventing catastrophic load levels from high-rate hardover surface commands and accelerations. This is 
illustrated in figures 17 through 20. Figure 17 shows the N z and N y response due to a nominal 1 g trim 
condition with a canard failure multiplier of -0.5 inserted at 5 s and a hardover inserted at 15 s. With the 
floating limiter engaged, the peak N z was approximately 2.5 g and the peak N y was smaller than -0.25 g. 
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Without the floating limiter engaged, the N z peaks at 1 1 g and the N y peaks at -2.5 g. Figure 18 shows the 
loads predicted for forward fuselage station FS400. With the floating limiter engaged, the loads are well 
below the 80% DLL limit. Without the floating limiter engaged, the loads build to over 200% DLL for 
both vertical shear and the vertical-bending-to-lateral-bending strength envelope. Figures 17 and 18 show 
a nominal 1 g trim condition with a left stabilator lock at trim deflection inserted at -0.5 s and a hardover 
inserted at 15 s; figure 19 shows the N z and N y response. With the floating limiter engaged, the peak N z 
was approximately 2.5 g and the peak N y was smaller than -0.25 g. Without the floating limiter engaged, 
the N z peaks at 8.5 g and the N y peaks at -1.75 g. Figure 20 shows the loads predicted for forward 
fuselage station FS400. With the floating limiter engaged, the loads are well below the 80% DLL limit. 
Without the floating limiter engaged, the loads build to over -150% DLL for vertical shear, and the 
vertical-bending-to-lateral-bending strength envelope peaked at almost -125% DLL. 


Floating limiter comparison: Canard multiple = -0.5 Gen2B controller from 
Mach 0.75 and an altitude of 20,000 ft. with 1 g trim 



No PAL hardover 
at 15 s 

PAL = 8 hardover 
at 15 s 


Figure 17. Simulated normal acceleration response, 1 g trim, canard multiplier of -0.5, with Airborne 
Research Test System hardover inserted at 15 s (PAL = 8, DAG = 28, CAT = 51). 
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% DLL % DLL % DLL 


Floating limiter comparison: Canard multiplier = -0.5 Gen2B controller from 
Mach 0.75 and an altitude of 20,000 ft. with 1 g trim 



No PAL hardover 
at 15 s 

PAL = 8 hardover 
at 15 s 


Figure 18. Simulated forward fuselage loads, 1 g trim, canard multiplier of -0.5, with Airborne Research 
Test System hardover inserted at 15 s (PAL = 8, DAG = 28, CAT = 5 1). 


24 


10 

8 

6 

4 

2 

0 

-2 

0.5 

0 

-0.5 

- 1.0 

-1.5 

- 2.0 


Floating limiter comparison: Left stabilator trim fail Gen2B controller from 
Mach 0.75 and an altitude of 20,000 ft. with 1 g trim 
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No PAL hardover 
at 15 s 

PAL = 8 hardover 
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Figure 19. Simulated normal acceleration response, 1 g trim, left stabilator locked at trim deflection, with 
Airborne Research Test System hardover inserted at 15 s (PAL = 8, DAG = 23, CAT = 51). 
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Floating limiter comparison: Left stabilator trim fail Gen2B controller from 
Mach 0.75 and an altitude of 20,000 ft. with 1 g trim 
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Figure 20. Simulated forward fuselage loads, 1 g trim, left stabilator locked at trim deflection, with 
Airborne Research Test System hardover inserted at 15 s (PAL = 8, DAG = 23, CAT = 51). 
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INTERACTIVE ANALYSIS AND DISPLAY SYSTEM DISPLAYS 


The NASA DFRC team replaced the MCC computers with PCs to enable utilization of the 
Symvionics (Arcadia, California) real-time display system called the Interactive Analysis and Display 
System (IADS). Three of the MCC displays developed by the systems engineers are shown in figures 21, 
22, and 23. The basic F-15 systems display page is shown in figure 21. Signals such as aircraft health, 
mode, configuration, surface positions, and fuel quantities are shown. Failures were programmed to 
display in red. The IADS design environment enables quick prototyping of display pages including 
derived parameters using C-type expressions. For example, when a BLIN code is set, the display is 
programmed to blink to capture the attention of the systems engineer so that another page may be selected 
for viewing a code description. The primary NN display page is shown in figure 22. This page displays 
the selected PVI parameters (PAL, DAG, and CAT). If a PAL limit has been exceeded, that limit will 
display in red and will “latch” until the pilot cycles the mode switch in the cockpit. The NN weights 
display page is shown in figure 23 . The weights for each axis are displayed in both strip chart and tabular 
form. Some of the components used to build an IADS display will now be discussed. 
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Figure 21. The interactive analysis and display system: the basic F-15 systems display page. 
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Figure 22. The interactive analysis and display system: neural network systems page 1. 
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Figure 23. The interactive analysis and display system: neural network systems page 2. 

Alphanumeric Widgets 

The alphanumeric widget display types were used in great number because they enabled easy creation 
of derived parameters and permitted multiple test strings to be displayed depending on the value of that 
signal. String colors were added, corresponding to different signal values. The alphanumeric widget data 
structure enabled the display and processing of a large amount of information. 

Strip Charts 

Multiple parameters displaying assigned colors were also used in a single strip chart so that if a 
particular test event was missed, the scroll bar on the far right could be used to go back in time to view 
the event. 


Slider Bars 

A slider bar was also implemented, to assist with visualization of the control surface motion in 
relation to the other surfaces. The slider bar is shown in figure 24. 
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Figure 24. The slider bar display. 


Latched Functions 

The latched functions feature was created as a derived parameter. For example, peak maximum and 
minimum NN commands were programmed in IADS to show the limit excursions. Latching reset logic 
was also performed in the IADS configuration files. 

Flasher Functions 

Flasher functions were used on the IADS display to enhance human awareness of any serious 
problem that required immediate response. The flashers were used for an F-15 BLIN code situation, and 
to indicate if the display pages were not receiving new data. 

Built-in Displays 

One of the built-in IADS displays for the attitude displacement indicator (ADI) is shown in figure 25. 
This display provided situational awareness to the control room of the airplane attitude. 
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Figure 25. The attitude displacement indicator display. 

FLIGHT-TEST RESULTS 

This section discusses the comparison of the flight-test results and the simulation. The stick and 
rudder positions from flight were recorded and used as inputs to drive the simulation. The flight-test 
results are from the Gen 2a adaptive controller with a left stabilator failed at trim 7.5 s into the maneuver. 
The flight conditions were Mach .75 at an altitude of 20,000 ft. The flight response data (pitch and roll 
stick, rudder pedals, and throttle commands) were recorded from flight and back-driven into the 
simulation to see how closely the responses would match. Figure 26(a) shows the angle of attack (alpha) 
and bank angle (phi) from the flight (blue) and the simulation (red). Figure 26(b) shows the flight (blue) 
roll rate, p, pitch rate, q, and the yaw rate, r, and the simulation (red) p, q, and r. Neural network outputs, 
which are the roll axis signal, the pitch axis signal, and the yaw axis signal, are shown in figure 26(c): 
flight data is displayed in blue, and simulation results in red. 
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(a). Flight (blue lines) to simulation (red lines) comparison of alpha and phi for left; the stabilator jammed 
at 7.5 s. 
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(b). Flight (blue lines) to simulation (red lines) comparison of p, q, and r for left; the stabilator jammed 
at 7.5 s. 


Figure 26. Comparisons of flight to simulation. 
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(c). Flight (blue lines) to simulation (red lines) comparison of the neural network signals for left; the 
stabilator jammed at 7.5 s. 


Figure 26. Concluded. 

The flight-to-simulation comparison time histories match very well. The results show that the 
simulation did a very good job of predicting the behavior of the actual aircraft response. The only 
exception is the yaw axis NN signal shown in figure 26(c); however, upon closer examination of this 
signal the size or magnitude of the yaw axis signal can be observed to be very small. The yaw axis 
response is very difficult to match even in a healthy airplane. 

CONCLUSION 

A safe, cost-effective approach was undertaken by the NASA Dryden Flight Research Center 
(Edwards, California) to investigate experimental adaptive control algorithms. This approach utilized a 
simplified, single-string Airborne Research Test System that interfaced with the existing flight control 
computers of the McDonnell-Douglas NF-15B airplane. The pilot-vehicle interface design allowed for 
flexibility of various options during the flight tests. All Generation 2a software was verified and validated 
using the Dryden F-15 simulation. The pilot-vehicle interface design also allowed for considerable 
flexibility in selecting such neural network algorithms, failure combinations, and excitations systems as 
were required for flight test. 

The verification and validation of the neural network software was thorough and efficient. Some of 
the problems that were identified were corrected with new configuration files not requiring a new compile 
of the operational flight program. Certain DRs were considered minor and were not fixed; these were 
handled using procedures to work around the problem. 

Safety was the primaiy consideration in preparing for flight test. Any problem with the neural 
network would result in a downmode back to the conventional flight control computer control laws. The 
worst case scenario that was considered was if the neural network commands were to go hard over 
(command a rapid and sustained displacement of an aircraft aerodynamic control surface). A floating 
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limiter was designed to protect the structure forces of the airplane and to meet the pilot-imposed 
maximum g excursions. A loads model in the Diyden simulator was used extensively to validate the 
floating limiter disengage metrics. 

Interactive analysis and display system display pages, developed by the flight-test engineers for 
monitoring in the Mission Control Center, proved to be easy to build and very effective. The derived 
functions capability within the interactive analysis and display system helped immensely to convert raw 
signal constructs into user-friendly formats that provided insight to both the neural network and the basic 
F-15 airplane systems. 
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